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(57) The method for privacy-protecting integrity at- 
testation of a computing platform (P) having a trusted 
platform module (TPM) comprises the following steps. 
First, the computing platform (P) receives configuration 
values (PCR1 ... PCRn). Then, by means of the trusted 
platform module (TPM) a configuration value (PCRp) is 
determined which depends on the configuration of the 



computing platform (P). In a further step the configuration 
value (PCRp) is signed by means of the trusted platform 
module (TPM). Finally, in the event thatthe configuration 
value (PCRp) is one of the received configuration values 
(PCR1 ... PCRn), the computing platform (P) proves to 
a verifier (V) that it knows the signature (sign(PCRp)) on 
one of the received configuration values (PCR1 ... 
PCRn). 
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Description 
TECHNICAL FIELD 

5 [0001] The present invention relates to a method for privacy-protecting integrity attestation of a computing platform, 
a computing platform for privacy-protecting integrity attestation, and a network for privacy- protecting communication. 

BACKGROUND OF THE INVENTION 

10 [0002] Processing critical information relies on the security of the computing platform. Typical security goals are to 
prevent such critical information from leaking beyond the realm of machines that are trusted by the user or to prevent 
corrupted machines from impacting the integrity of a computation. External verification of platform integrity enables a 
machine to verify that another machine meets certain security requirements. This is useful, for example, when a grid 
server wants to assure that a grid node is untampered before delegating a grid process to it. 

15 [0003] In the following example two computers or machines A and B interact over a network. In the example machine 
A can make certain statements about its own state, e.g. "I am in status access" or "My software ... is in status x", or 
deliver a hash or checksum of this status (h(x)), or certain properties, e.g. "I am running version ... of Linux". Machine 
A can send these statements to machine B, but why should machine B trust machine A with respect to the correctness 
of these statements? If machine A is corrupted by a hacker, it could make arbitrary claims about itself. 

20 [0004] Therefore, it is desired to implement a proving method with which machine B can verify whether the statements 
made by machine A are correct. The embodiment of such a proving method is shown in FIG. 1 . In the following, machine 
A is called verified machine or the prover and machine B the verifier. All solutions to this problem assume that there is 
a piece of hardware, called trusted platform module TPM, which cannot be compromised, and which can make reliable 
statements about the rest of the system A. Specifically, the industry consortium Trusted Computing Group (TCG) has 

25 specified the trusted platform module TPM, which can compute a checksum of the system configuration of machine A, 
wherein the checksum can be computed for a system configuration in which all or only a part of the software is running 
on machine A. In a further step the computed checksum is signed, and afterwards send off to the verifier B. The 
corresponding protocol is shown in FIG. 2. 

[0005] The Trusted Computing Group is an IT industry consortium which has developed a specification of a small, 
30 low-cost commodity hardware module, called trusted platform module (TPM). The TPM can serve as a root of trust in 
remote (and local) platform verification. The base TCG model of this configuration verification process, called binary 
attestation, aims at measuring all executed code. Therefore, each measured piece of software stores metrics of a 
sub-component into the TPM before executing it, wherein the metrics are hash values of the configuration's components. 
The metrics are bootstrapped by the basic input output system (BIOS) that is trusted by default and that is measuring 
35 and storing the boot loader. The chain of trust can then be extended to the operating system components and to the 
applications and their configuration files. Once the executables are measured into the TPM, the TPM can reliably attest 
to the metrics of the executed components by signing the metrics with a TPM-protected key. The signed metrics, also 
called integrity metrics, can then be transmitted to a verifying machine. This verifier machine, or in short verifier, can 
decide whether to consider the verified machine trustworthy enough to involve it in a subsequent computation. As will 
40 be elaborated hereinafter, this straightforward approach of binary attestation lacks privacy. The main reason therefore 
is that the whole configuration is transmitted. 

[0006] Hereinafter, the binary attestation and verification is explained. The ability of the TPM reliably to report on the 
verified platform's computing environment follows from the TPM-enabled measurement and reporting. The description 
in the following paragraphs focuses on a PC-platform. Nevertheless, the TPM can be implemented in any platform or 

45 computing device, e.g. mobile phone, PDA, notebook, etc. The measurement and storage of integrity metrics is started 
by the BIOS boot block (a special part of the BIOS which is believed to be untampered) measuring itself and storing the 
measurements in a TPM PCR (platform configuration register) before passing control to the BIOS. In the same way, the 
BIOS then measures option ROMs and the boot loader and records these measurements in a TPM PCR before passing 
control to the boot loader. The process continues as the boot loader measures and stores integrity metrics of the operating 

50 system (OS) before executing it. The OS in turn measures and stores integrity metrics of additionally loaded OS com- 
ponents before they are executed. If support by the OS is provided, applications can also be measured before being 
executed. The measurement and reporting processes are depicted in a simplified manner in FIG. 2, in which '/-/represents 
the cryptographic hash function SHA-1 . During initialization, various platform configuration registers PCRx as well as a 
configuration log file fog (stored on the platform) are initialized. This log file log keeps track of additional information 
such as descriptions or file paths of loaded components. Its integrity needs not to be explicitly protected by the TPM. 

55 During subsequent measurement of components, this log file fog is extended, while metrics (hash values) of the exe- 
cutables are stored in the TPM using the tpm_extend method replacing the contents of the appropriate platform config- 
uration register PCRx with the hash of the old contents and the new metrics, wherein metrics of loaded components are 
reliably stored in the TPM. When a remote verifier B wants to assess the security of the verified platform A, the verifier 
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B sends a challenge c to the platform A. The platform A uses this challenge c to query with a tpm_quote command the 
TPM for the value of the platform configuration registers PCR. The TPM responds with a signed message qu = sign A)K 

( PCR , c) containing the PCR values and the challenge c. The platform A returns this signed quote qu to the challenger 

5 (verifier B) together with information from the log file log needed by the verifier B to reconstruct the verified platform's 
configuration. The verifier B can then decide whetherthis configuration is acceptable. The key used for signing the quote 
is an attestation identity key AIK of the TPM. As a TPM may have multiple attestation identity keys, the key or its identifier 
has to be specified in the tpm_quote request. An attestation identity key AIK is bound to a specific TPM. Its public part 
is certified in an attestation identity key certificate by a privacy-certification authority as belonging to a valid TPM. The 

10 verifier of a quote signed with a correctly certified AIK believes that the quote was produced by a valid TPM, more 
specifically, by the unique TPM owning that AIK. This belief is based on the assumption that the TPM is not easily subject 
to hardware attacks and that effective revocation mechanisms are in place dealing with compromised keys. 
[0007] Note that the above measurement process does not prohibit execution of untrusted code, it only guarantees 
that the measurement of such code will be securely stored in the TPM. Thus, if malicious code is executed, the integrity 

15 of the platform A may be destroyed. However, the presence of an untrusted or simply unknown component will be 
reflected by the TPM quotes not matching the correct or expected values. 

[0008] Further information about the Trusted Computing Group and the trusted platform module can be found in The 
Trusted Computing Group, Main specification version 1.1b, 2003, which is available from http://www.trustedcomputing- 
group.org. 

20 [0009] The trusted platform module TPM also supports trusted booting, which means that the prover A can go through 
a sequence of steps. In each step a new component is loaded e.g., first the boot loader, then the operating system, and 
then an application. The TPM ensures that each step succeeds only if all previous steps succeeded. Via trusted booting 
one can ensure that the prover A boots into a known, well-defined state, with certain properties. 
[0010] A related, theoretically well investigated feature is secure booting. The difference to trusted booting is that a 

25 system with secure booting either boots a specific, pre-defined system or does not boot at all, while a system with trusted 
booting can boot any system, but certain data are accessible only if it boots into a pre-defined system. The details of 
how a secure boot process can be carried out can be looked up in B. Yee, "Using secure coprocessors", Technical 
Report CMU-CS-94-149, Carnegie Mellon University School of Computer Science, May 1994. 

[001 1] The above mentioned TCG specifications define mechanisms for a TPM-enabled platform to reliably report its 
30 current hardware and software configuration to a local or remote challenger. This binary attestation, based on meas- 
urements of binary executables, firstly requires that the platform builds a chain of trust from the hardware up to the 
operating system and potentially, including applications by measuring integrity metrics of modules and storing them in 
the TPM, and secondly requires that the TPM is able to report on these integrity metrics in an authenticated way. A 
verifier obtaining such authenticated integrity metrics can then match them against the values of a known configuration 
35 and decide whether the verified machine meets the security requirements or not. But with that, the privacy of the verified 
machine is violated, because with this approach the prover needs to reveal its configuration. The verifier gets information 
about the configuration of the verified machine, e.g. which operating system and which applications are running on the 
verified machine. This will not be acceptable to consumer since it raises substantial privacy concerns. 

40 SUMMARY OF THE INVENTION 

[0012] Therefore, an object of the invention is to provide a method for privacy-protecting attestation of a computing 
platform, where the computing platform can keep its configuration secret. That is the computing platform does not have 
to reveal its configuration. 

45 [0013] According to one aspect of the invention, the object is achieved by a method for privacy-protecting integrity 
attestation of a computing platform with the features of the independent claim 1 . 

[0014] The method for privacy-protecting integrity attestation of a computing platform having a trusted platform module 
comprises the following steps. First, the computing platform receives configuration values. Then, by means of the trusted 
platform module a configuration value is determined which depends on the configuration of the computing platform. In 
50 a further step the configuration value is signed by means of the trusted platform module. Finally, in the event that the 
configuration value is one of the received configuration values, the computing platform proves to a verifier that it knows 
the signature on one of the received configuration values. 

[0015] According to another aspect of the invention, the object is achieved by a computing platform for privacy-pro- 
tecting integrity attestation. 

55 [0016] The computing platform for privacy-protecting integrity attestation according to the invention is formed such 
that it is able to receive configuration values and comprises a trusted platform module which in turn is formed such that 
it is able to determine a configuration value depending on the configuration of the computing platform, and to sign the 
configuration value. Furthermore, the computing platform is formed such that in the event that the configuration value 
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is one of the received configuration values it is able to prove to a verifier that it knows the signature on one of the received 
configuration values. 

[0017] According to a further aspect of the invention, the object is achieved by a network for privacy- protecting com- 
munication. 

5 [001 8] The network for privacy-protecting communication according to the invention comprises a verifier, and a com- 
puting platform having a trusted platform module, wherein the computing platform is formed such that it is able to receive 
configuration values, e.g. from the verifier. The trusted platform module is formed such that it is able to determine a 
configuration value depending on the configuration of the computing platform, and to sign the configuration value. The 
computing platform is furthermore formed such that in the event that the configuration value is one of the received 

10 configuration values it is able to prove to the verifierthat it knows the signature on one of the received configuration values. 
[0019] Advantageous further developments of the invention arise from the characteristics indicated in the dependent 
patent claims. 

[0020] Preferably, in the method according to the invention the proof is carried out by a cryptographic proof. 
[0021] Advantageously, in the method according to the invention the proof is carried out by a zero-knowledge proof. 
15 With that, it can be ensured that the information the verifier gets from the computing platform does not contain any 
knowledge about the configuration of the computing platform itself. 

[0022] In an embodiment of the method according to the invention the computing platform checks after receiving the 

configuration values whether configurations having the received configuration values actually may exist, and if this is 

the case the above described method is further processed. With that, the privacy-protection can be further improved. 
20 [0023] In another embodiment of the method according to the invention the computing platform checks whether the 

number of received configuration values exceeds a minimum number of configuration values, and if this is the case the 

above described method is further processed. With that, the privacy-protection can be further improved. 

[0024] The present invention also relates to a computer program element comprising program code for performing 

the above described method when loaded in a digital processor of a computer. 
25 [0025] Finally, the present invention also relates to a computer program product stored on a computer usable medium, 

comprising computer readable program code for causing a computer to perform the above described method. 

[0026] Additional objects and advantages of the invention will be set forth in the description which follows, and in part 

will be obvious from the description, or may be learned by practice of the invention. 



30 BRIEF DESCRIPTION OF THE DRAWINGS 



[0027] The invention and its embodiments will be more fully appreciated by reference to the following detailed de- 
scription of presently preferred but nonetheless illustrative embodiments in accordance with the present invention when 
taken in conjunction with the accompanying drawings. 
35 [0028] The figures are illustrating: 

FIG. 1 a block diagram of the architecture for a system for binary attestation according to the prior art, 

FIG. 2 a protocol for the architecture shown in FIG. 1 , and 

FIG. 3 a block diagram of the architecture for a system for privacy-protecting attestation of the integrity of a computing 

40 platform according to the invention. 



DETAILED DESCRIPTION OF AN EMBODIMENT 



[0029] The description of the FIGs. 1 and 2 is in section "Background of the invention". 
45 [0030] Below is described a way how to implement privacy-friendly attestation where the prover and the verifier ensure 
that the prover has one of the given configurations without revealing which one. As a consequence, the verifier learns 
nothing except that the prover has a correct or permissible configuration. This enhances the privacy of the prover 
substantially. 

[0031] In FIG. 3 a block diagram of the architecture for a system for privacy- protecting attestation of the integrity of a 
50 computing platform according to the invention is depicted. A computing platform P, in the following also called platform 
or prover, comprises a trusted platform module TPM that measures the platform P. This measurement results in a 
platform configuration register value stored in a platform configuration register (PCR). Different PCR values correspond 
to different configurations of the platform P. To convince the verifier V that the platform P is in a certain configuration, 
the TPM signs the measured PCR value PCRp with respect to an attestation identity key AIK which comprises an RSA 
55 public/secret key pair. Afterwards, the TPM sends the PCR value PCRp and its signature sign A!K (PCRp) to the local 
verification component, which is a part of the platform P. It receives the PCR value PCRp and its signature sign A | K (PCRp) 
and then runs the protocol below. That is, the platform P is given the PCR value, the RSA signature on the PCR value, 
and the RSA public key part of the attestation identity key AIK. The platform P wants to produce from this a proof that 
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it knows an RSA signature with respect to this attestation identity key AIK on, e.g., one out of a list of PCR values. In 
the following it is described how this can be achieved. 

[0032] By using a cryptographic proof, particularly a zero-knowledge proof, the prover P can prove its integrity to the 
verifier without revealing its configuration. This means, the prover P can proof to the verifier V by means of the crypto- 
5 graphic proof that its configuration is indeed one of the configurations the verifier V has specified as being correct or 
permissible. 

[0033] The protocol described below uses techniques devised by Louis C. Guillou and Jean-Jacques Quisquater, 
"A "paradoxical" identity-based signature scheme resulting from zero-knowledge" in Shafi Goldwasser, editor, Advances 
in Cryptology - CRYPTO '88, volume 403 of LNCS, pages 216 - 231, Springer Verlag, 1988, Ronald Cramer, Ivan 

10 Damgard, and Berry Schoenmakers "Proofs of partial knowledge and simplified design of witness hiding protocols" in 
Yvo G. Desmedt, editor, Advances in Cryptology - CRYPTO '94, volume 839, pages 174 - 187, Springer Verlag, 1994, 
and Alfredo De Santis, Giovanni Di Crescenzo, Giuseppe Persiano, and Moti Yung "On monotone formula closure of 
SZK" in 35th Annual Symposium on Foundations of Computer Science, pages 454 - 465, Santa Fe, New Mexico, 20-22 
November 1994, IEEE. In the following key notions are briefly recalled and some notations used are described. For 

15 details reference is made to the above mentioned papers. 

[0034] Let 6 denote a smooth secret sharing scheme and s a secret that is shared among n participants, each having 

an element of the set of secret shares {s^ s n }. A qualified set of secret shares for 6 is a set of shares that allows to 

reconstruct s. The access structure r is the set of index sets that contain the indices of secret shares being qualified sets. 
[0035] The dual access structure to the access structure r is denoted by r* and defined by: 

20 



25 [0036] By definition of a smooth secret sharing scheme 6 there exist algorithms as follows: 

[0037] A first algorithm is called "is-consistent (s, {s-,, s n }, r)", whereas the first argument s of the algorithm is a 
secret, the second argument {s-,, s n } is a full set of secret shares, and the third argument r is an access structure. 
The algorithm is-consistent (s, {s 1? s n }, r) returns 1, if all qualified sets in r determine s as the secret. Such a triple 
(s, {s-,, s n }, r) is called consistent. Otherwise the algorithm returns {}. 

30 [0038] A second algorithm is called "complete (s, {s-|, s k }, T)", whereas the first argument s of the algorithm is a 
secret, the second argument {s-,, s k } is a set of incomplete shares, i.e., a not qualified set of shares, and the third 
argument r is an access structure. The algorithm complete (s, {s 1; s k }, T) returns a set of shares S such that S u 
{s^ s k } is consistent, whereas {s-,, s k } n S = {}. 

[0039] This general technique allows one to prove arbitrary statements, for instance "I know a signature on PCR1 and 
35 PCR2 or one on PCR2 and PCR3 or one on PCR4." In practice, however, the statement will often be "I know a signature 
on one out of the following PCR1 , PCR2, PCR3, and PCR4." In this case, the secret sharing scheme G can be realized 
quite simply: If the secret s is a secret k-bit string, choose k - 1 shares Sj as random k-bit strings and then set the share s k to: 

40 s k = s © (©JlJSi) = s © s ± ® s 2 © . . . s k _ a 

wherein © denotes a XOR-operation. 

That is, the algorithm is-consistent (s, {s-,, s n }, r) checks whether the secret s holds the condition: 

45 
50 

[0040] The algorithm complete (s, {s 1f Sj_-,, Sj +1 , s k }, r) sets the share Sj to: 

55 

[0041] In the following is described how the knowledge of a RSA signature can be proved. 

[0042] Let m be the message that is signed, a the signature on the message m, and (e, n) the public key of the signer, 
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wherein the signer is for example the TPM and in the context of TCG the exponent e = 2 16 - 1 . Let H be the encoding 
function as defined in PKCS#1 V1 .5 (RSA Encryption Standard, http://www. rsasecurity.com/rsalabs/node. asp? id=21 25). 
The value a is a valid signature on the message m if a e = H(m) (mod n) with respect to the public key (e, n). 
[0043] Considering now a zero knowledge protocol that allows the prover P to convince the verifier V that it knows a 
5 signature a on a message m with respect to the public key (e, n) where the verifier V is allowed to learn the message 
m and the public key (e, n) but not the signature a. 

[0044] It is assumed that the zero knowledge protocols run in practice in non-interactive mode. That is, one can use 
the Fiat-Shamir heuristic with the protocols. The Fiat-Shamir heuristic is described in Amos Fiat and Adi Shamir "How 
to prove yourself: Practical solutions to identification and signature problems" in Andrew M. Odlyzko, editor, Advances 
10 in Cryptology - CRYPTO '86, volume 263 of LNCS, pages 1 86 - 1 94, Springer Verlag, 1 987. In this mode, the challenge 
c in the protocol is determined via a hash-function on the first message t in the protocol and the protocol's public inputs. 
[0045] One way to achieve the required proof is to apply the protocol by Louis C. Guillou and Jean-Jacques Quisquater, 
"A "paradoxical" identity-based signature scheme resulting from zero-knowledge" in Shafi Goldwasser, editor, Advances 
in Cryptology - CRYPTO '88, volume 403 of LNCS, pages 21 6 - 231 , Springer Verlag, 1 988. It works as follows: 

15 

1 . The prover P carries out the following steps: 

The prover P chooses a random value r, wherein r e Z* N , sets the first message t to: 



20 t = r e modN, 

and sends the first message t to the verifier V. 

2. Afterwards, the verifier V carries out the following steps: 

25 The verifier V chooses a random value c, wherein c e y [0, e - 1 ], and sends the random value c to the prover P. 

3. Afterwards, the prover P carries out the following steps: 

The prover P computes the response value res = r • a c mod N, and sends the response value res to the verifier V. 

4. Finally, the verifier V carries out the following step: 

? 

30 The verifier V outputs the value of the predicate r £ S e == X(H(m))° mod N 

[0046] This protocol provides a security assurance of 1/e which is about 2 -16 in the TCG case. If the protocol is run 
interactive, one should repeat it at least 4 times. If the protocol is run in n on -interactive mode, i.e., when a hash function 
35 I Fiat-Shamir heuristic is applied to compute the challenge, one should run the protocol about 1 0 times. 

Specification of a privacy friendly attestation protocol 

[0047] It is denoted the set T of publicly known PCR values that are considered correct by T = {PCR1 , ... , PCRn}. 
40 The prover's AIK signing- / verification - key pair is denoted by (S A(K , V A , K )- The signature o on the message m is a = 
sign(S A | K , m), which can be verified by evaluating the predicate verify(V A | K , a). More precisely, the verification key V AIK 
consists of the integers (N, e) where N is a RSA modulus and e is a prime exponent. 

[0048] Let A v = {i-,, i m } the set of indices of the PCR values for which the prover P knows a signature. That is, the 
prover P knows a set of signatures S: 

45 

S = {oil = sign(S A nc, PCRii), ...,c im = sign(S A iK, PCRi m )} 

50 [0049] It is A v an index set, and A-,, A k c{1, n} arbitrary index sets. It is noted that for the PCR values described 
by the index sets A-,, A k the prover P does not need to know the corresponding signatures. Finally G denotes the set 
of index sets {A v , A-,,..., A k }. 

[0050] The above described privacy friendly attestation protocol allows the prover P to assert to the verifier V that it 

knows signatures on the PCR values described by one of the index sets {A v , A-, A k } in the set G. Thereby the verifier 

55 V does not get any information for which of the index sets {A v , A-,, A k } in the set G the prover P knows the signature 
or signatures o. 

[0051] In the following a protocol for implementing the invention is described. Common inputs to the prover P, and 
the verifier V are: C = {0, c+}, the set of public known correct PCR values T, the set G, and the verification key V A!K . 
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Private inputs to the prover P are: the set of signatures S, and the index set A v . The joint computation of the prover P, 
and the verifier V is as follows. 

1 . The prover P carries out the following steps: 

5 

a) The prover P chooses for each j e A v a random value rj wherein rj e Z* N , and sets the value tj to: 

tj == if mod N. 

10 

b) The prover P chooses for j e Av a response value resj e y Z* N , c e u C, and sets the value tj to: 

« tj - res/ (H(PCRj)y c mod N 

It is noted that the index set Ay is tne complement of the index set A v in {1 , n}. 

c) The prover P sends the messages (t 1f t n ) to the verifier V. 

20 

2. After that, the verifier V carries out the following steps: 

The verifier V chooses a random value c wherein c e u C, and sends the random value c to the prover P. 

3. After that, the prover P carries out the following steps: 



25 _ 

C = complete(c, {q : i e Ay}, r*). 

a) The prover P computes for j e A v : c } e 5 the response value resj = ^ aj c J mod N. 

b) The prover P sends ((res-|, c-|), (res n , c n )) to the verifier V. 

30 

Remark: For j e Ay tne ( res j> c j) were already computed in the round 1 . 

4. The verifier V carries out the steps: 

The verifier V outputs the value of the following predicate: 

35 



n s. e a t.(H(PCRj) ) cj mod nJ 



s, e = t.(H(PCRj) ) cj mod N a is-consistent (c, {ci, c n }, T) 



40 

wherein A denotes an AND-operation. 



[0052] In the above described protocol the random value c is interpreted as secret and Cj as share of the secret c and 
the Cj are the challenges in the zero knowledge protocol with which is proofed that a signature on the PCRi value is known. 
[0053] As mentioned in the previous section, c + < e should hold for this proof to work. Also, the secret sharing scheme 
G should be compatible with this. In practice, one would run many, e.g., 10 instances of this protocol in parallel and 
determine c via a hash function of all the first messages, i.e., the tuples (t,,..., t n ), the involved AIK and all the PCR 
values. More precisely, the one would concatenate for each i the q (about 16 bits each) from all the protocol instances, 
to obtain a larger Cj (about 1 60 bits), then use the hash function to determine c (e.g., 1 60 bits), use the secret sharing 
scheme to obtain the remaining Sj, (e.g., 1 60 bits), split then into smaller parts (e.g., 16 bits) and use each of these small 
parts with on the parallel protocol instance. 

[0054] Which configuration values are permissible configuration values is defined by the verifier V. For example, the 
verifier V can mark a configuration value as not permissible if the corresponding configuration does not fulfill the desired 
security properties. 

[0055] Abuse might arise if a configuration value is indicated as permissible by the verifier V but does not represent 
a possible configuration. If the verifier V transmits such improper configuration or dummy values together with a proper 
configuration value PCRs actually representing a possible configuration to the prover P the verifier V might spy out the 
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actual configuration of the prover P. Because the set of transmitted configuration values comprises mainly dummy 
values, the prover P can only prove to the verifier V that its configuration is the configuration corresponding to the 
configuration value PCRs and with that the verifier V knows the actual configuration of the prover P. If the prover P 
cannot prove that its configuration is in the set oftransmitted configuration values, i.e. its configuration does not correspond 

5 to the configuration value PCRs, the verifier V can transmit a further slightly modified set of configuration values to the 
prover P and repeat the procedure until it has found out the actual configuration of the prover P. To prevent this kind of 
abuse the method according to the invention can comprise the following step. After the prover P has received the 
permissible configuration values PCR1 ... PCRn the prover P checks whether configurations having the configuration 
values PCR1 ... PCRn actually may exist, and if this is the case the integrity proof is processed. Otherwise the prover 

10 p can for example abort the proof or ask the verifier V for a new set of configuration values. 

[0056] A similar abuse by the verifier V may occur if the verifier V transmits only a very small number of configuration 
values to the prover P. Also in this case the verifier V has the possibility to spy out the actual configuration of the prover. 
If for example the verifier V transmits only one configuration value to the prover P, the prover P can only prove whether 
its configuration corresponds to transmitted configuration value or not. In the case the configuration of the prover P 

75 corresponds to the transmitted configuration value the prover P proves this to the verifier V and with that the verifier V 
has learned the configuration of the prover. To avoid this, the prover P can check whether the number of transmitted 
configuration values does not fall under a minimum number of transmitted configuration values. If the number of trans- 
mitted configuration values exceeds the necessary minimum number the integrity proof is processed. Otherwise the 
prover P can for example abort the proof or ask the verifier V for a bigger set of configuration values. 

20 [0057] Computer readable program code or program code in the present context mean any expression, in any language, 
code or notation, of a set of instructions intended to cause a system having an information processing capability to 
perform a particular function either directly or after either or both of the following a) conversion to another language, 
code or notation; b) reproduction in a different material form. 

25 

Claims 

1. Method for privacy- protecting integrity attestation of a computing platform having a trusted platform module (TPM), 
comprising: 

30 

a) receiving configuration values (PCR1 ... PCRn), 

b) determining by means of the trusted platform module (TPM) a configuration value (PCRp) depending on the 
configuration of the computing platform (P), 

c) signing by means of the trusted platform module (TPM) the configuration value (sign(PCRp)), and 

35 d) in the event that the configuration value (PCRp) is one of the received configuration values (PCR1 ... PCRn), 

the computing platform (P) proving to a verifier (V) that it knows the signature (sign(PCRp)) on one of the 
received configuration values (PCR1 ... PCRn). 

2. Method according to claim 1 , 

40 wherein the proof is carried out by a cryptographic proof. 

3. Method according to claim 1 or 2, 

wherein the proof is carried out by a zero-knowledge proof. 

45 4. Method according to any of the previous claims 1 to 3, 

- wherein after receiving the configuration values (PCR1 ... PCRn) the computing platform (P) checks whether 
configurations having the configuration values (PCR1 ... PCRn) actually may exist, and 

- if this is the case the method is further processed. 

50 

5. Method according to any of the previous claims 1 to 4, 

wherein the computing platform (P) checks whetherthe number of received configuration values exceeds a minimum 
number of configuration values, and 

55 - jf this is the case the method is further processed. 

6. Computer program comprising program code for performing the steps of the method according to any of the previous 
claims 1 to 5 when loaded in a digital processor of a computer. 
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Computer program product stored on a computer usable medium, comprising computer readable program code for 
causing a computer to perform the steps of the method according to any of the previous claims 1 to 5. 

A computing platform for privacy-protecting integrity attestation, the computing platform (P) being adapted to receive 
configuration values (PCR1 ... PCRn), comprising: 

a trusted platform module (TPM) that is adapted 

to determine a configuration value (PCRp) in dependence on the configuration of the computing platform (P) and 
to sign the configuration value (sign(PCRp)), and 

wherein the computing platform (P) comprises the functionality that in the event that the configuration value 
(PCRp) is one of the received configuration values (PCR1 ... PCRn) the computing platform (P) is adapted to 
prove to a verifier (V) that it knows the signature (sign(PCRp)) on one of the received configuration values 
(PCR1 ... PCRn). 

A network for privacy- protecting communication, comprising: 

- a computing platform (P) having a trusted platform module (TPM), and 

- a verifier (V) connected to the computing platform (P), 

wherein the computing platform (P) is adapted to receive configuration values (PCR1 ... PCRn), 
wherein the trusted platform module (TPM) is adapted 

to determine a configuration value (PCRp) in dependence on the configuration of the computing platform (P) and 
to sign the configuration value (sign(PCRp)), and 

wherein the computing platform (P) comprises the functionality that in the event that the configuration value (PCRp) 
is one of the received configuration values (PCR1 ... PCRn) the computing platform (P) is adapted to prove to the 
verifier (V) that it knows the signature (sign(PCRp)) on one of the received configuration values (PCR1 ... PCRn). 
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